Many organizations utilize complex software systems, such as Enterprise Resource Planning (ERP) systems, for conducting almost all aspects of their business. The software systems may involve many different software modules. Typically, each time a module is installed, updated, and/or customized, it should be tested in order to verify that it is operating as expected. Consequently, organizations often devote many resources for the purpose of testing and validating the performance of their software systems.
However, creating the needed tests is not a trivial task. It is not always simple to determine what elements need to be tested (e.g., which software modules, business processes, and/or transactions), or how to conduct the testing of those elements. For example, business processes may have different behaviors to cover different options, different users, and\or for special cases. Generating test that cover all cases in not trivial; it may require foresight, imagination, and experience that may not be available to the test designer. For example, the test designer may not be aware of certain options that are available in the system since they were never utilized by the organization to which the test designer belongs; however, a recent update to the system has caused these options to be applicable for the organization. In this case, the test designer may not anticipate, nor have knowledge of how to test, the new options.
Building an effective and relevant testing suite is usually a time-consuming process, built on trial and error and domain know-how. Until an effective testing suite is built, an organization may end up conducting inefficient and/or incomplete testing of its software systems. However, it is often the case that software systems belonging to different organizations utilize many software modules that are the same or similar, and/or software modules that involve similar customizations. Consequently, testers belonging to the different organizations often end up running tests for testing those same or similar components. Thus, were organizations able to utilize each other's testing-related knowledge, they would be able to expand their testing arsenal and come up with more effective, comprehensive, and relevant tests. For example, after an update to a certain software module, a certain organization may devise a few tests to verify the system's performance based on tests of other organizations, which may have identified and addressed certain aspects of the update which testers from the certain organization were unaware of. Thus, sharing of tests in this case may help organizations to generate relevant and effective tests more rapidly.